Skip to content

Example: Step by step walkthrough with `appimageupdatetool`

Kurt Pfeifle edited this page Jan 12, 2018 · 5 revisions

Writeup not yet complete!


This is a step by step walkthrough about the usage of appimageupdatetool. That tool is for the command line only. (It has a sibling tool though which has a graphical user interface, called AppImageUpdate.) Of course it also ships as an AppImage! However, when I downloaded it, I immediately renamed it from appimageupdatetool-185-1c72f3b-x86_64.AppImage to a shorter name I prefer for typing in the terminal, aiut.

wget https://github.com/AppImage/AppImageUpdate/releases/download/continuous/appimageupdatetool-185-1c72f3b-x86_64.AppImage -O ~/bin/aiut chmod +x ~/bin/aiut # Make it executable ! 

In my following protocol, I captured as much details as possible -- so be patient...

To not confuse readers too much about my shorthand naming of the tool, I also created a symlink named appimageupdatetool, which I will use for this walkthrough:

ln -s aiut ~/bin/appimageupdatetool 

If you paid close attention, you'll already start to draw two conclusions:

  1. AppImages do not seem to require the use of the .AppImage filename suffix!
  2. AppImages seem to work even when called via symbolic links!

Let's see.


--help

First, get an overview of the tool:

$> appimageupdatetool -h /tmp/.mount_aiktbOwQ9Wq/usr/bin/appimageupdatetool {OPTIONS} [path] AppImage companion tool taking care of updates for the commandline. OPTIONS: -h, --help -V, --version Display version and exit. -d, --describe Parse and describe AppImage and its update information and exit. -j, --check-for-update Check for update. Exits with code 1 if changes are available, 0 if there are not,other non-zero code in case of errors. -O, --overwrite Overwrite existing file. If not specified, a new file will be created, and the old one will remain untouched. -r, --remove-old Remove old AppImage after successful update --self-update path path to AppImage "--" can be used to terminate flag options and force all following arguments to be treated as positional options 

--describe | -d and --check-for-updates | -j

Looking at the info appimageupdatetool could provide, the -j and -d flags look promising:

 -d, --describe Parse and describe AppImage and its update information and exit. -j, --check-for-update Check for update. Exits with code 1 if changes are available, 0 if there are not,other non-zero code in case of errors. 

These help hints suggest (to me at least), that -j is meant for rather silent runs, whereas -d is verbose.

However, both are "verbose". In a way that is a bit inconsistent...

To show how AppImage updates work, I used zsync2-105-7fd1caa-x86_64.AppImage to test (knowing that zsync2-106-817978a-x86_64.AppImage{,.zsync} are already available on their respective GitHub release page and should serve as update seeds). Then I ran these two commands:

$> appimageupdatetool -d zsync2-105-7fd1caa-x86_64.AppImage 1>out_d 2>err_d ; echo $? 0 $> appimageupdatetool -j zsync2-105-7fd1caa-x86_64.AppImage 1>out_d 2>err_d ; echo $? 1 

Now for the outputs of the two commands. I prepend ERR: and OUT: to each line to show which lines go out which channel.

Param -d:

ERR: Fetching release information for tag "continuous" from GitHub API. ERR: OUT: Parsing file: /home/kp/AppImages/zsync2-105-7fd1caa-x86_64.AppImage OUT: AppImage type: 2 OUT: Raw update information: gh-releases-zsync|TheAssassin|zsync2|continuous|zsync2-*x86_64.AppImage.zsync OUT: Update information type: ZSync via GitHub Releases OUT: Assembled ZSync URL: https://github.com/AppImage/zsync2/releases/download/continuous/zsync2-106-817978a-x86_64.AppImage.zsync 

Param -j: (out_j is empty)

ERR: Fetching release information for tag "continuous" from GitHub API. 

Run first update process

Now run an update process:

$> time appimageupdatetool ~/AppImages/zsync2-105-7fd1caa-x86_64.AppImage ; echo $? Checking for updates... Fetching release information for tag "continuous" from GitHub API. ... done! Starting update... Fetching release information for tag "continuous" from GitHub API. 0% done Updating from GitHub Releases via ZSync 0% done zsync2: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage found, using as seed file zsync2: Target file: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage zsync2: Reading seed file: /home/kp/AppImages/zsync2-105-7fd1caa-x86_64.AppImage 0.59778% done (0.01 of 2.29 MiB)... zsync2: Reading seed file: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage zsync2: Usable data from seed files: 100.000000% zsync2: Renaming temp file zsync2: Fetching remaining blocks zsync2: Verifying downloaded file zsync2: checksum matches OK zsync2: used 2398208 local, fetched 0 100.00% done (2.29 of 2.29 MiB)... Update successful. New file created: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage real 0m4.819s user 0m0.216s sys 0m0.052s 0 

Less than 5 seconds!

But of course, this "fast" run had a reason, as you can easily see: Yes, I had zsync2-106-817978a-x86_64.AppImage already locally available -- hence the four lines:
"zsync2: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage found, using as seed file",
"zsync2: Reading seed file: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage",
"zsync2: Usable data from seed files: 100.000000%" and
"zsync2: used 2398208 local, fetched 0".

Why did I do this? I wanted to see if I could fool the tool and trick it into running an update which was very obviously not necessary. But the tool isn't THAT stupid...

Second round for update process

Last I remove the existing, most up to date zsync2-106-817978a-x86_64.AppImage.

$> rm -rf zsync2-106-817978a-x86_64.AppImage 

We should now see the update process when it really has to do some heavy lifting. This last piece of the walkthrough is what you normally do for any existing AppImage you have. The initial checks, run with -j and -d, were only out of pure curiosity. The first update run (while the requested newest version was already present) was additional curiosity....

The real update is simpler, faster and more efficient. It takes less than half a minute:

$> time appimageupdatetool ~/AppImages/zsync2-105-7fd1caa-x86_64.AppImage ; echo $? Checking for updates... Fetching release information for tag "continuous" from GitHub API. ... done! Starting update... Fetching release information for tag "continuous" from GitHub API. 0% done Updating from GitHub Releases via ZSync 0% done zsync2: Target file: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage zsync2: Reading seed file: /home/kp/AppImages/zsync2-105-7fd1caa-x86_64.AppImage zsync2: Usable data from seed files: 48.761742% zsync2: Renaming temp file zsync2: Fetching remaining blocks 48.76% done (1.11 of 2.29 MiB)... zsync2: Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/105511842/13b63fa8-f04c-11e7-9b2d-9124208a76e2?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20180112%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20180112T024939Z&X-Amz-Expires=300&X-Amz-Signature=c251c07d3fe9e38fbae195c84ea8ad8e176006ebe38d0fe14e2bab1710c72a79&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dzsync2-106-817978a-x86_64.AppImage&response-content-type=application%2Foctet-stream 99.57% done (2.28 of 2.29 MiB)... zsync2: Verifying downloaded file zsync2: checksum matches OK zsync2: used 1169408 local, fetched 1228208 100.00% done (2.29 of 2.29 MiB)... Update successful. New file created: /home/kp/AppImages/zsync2-106-817978a-x86_64.AppImage real 0m22.792s user 0m0.276s sys 0m0.104s 0 

Clone this wiki locally